home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 10817 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.3 KB
  1. Path: azure.dstc.edu.au!crawley
  2. From: crawley@dstc.edu.au (Stephen Crawley)
  3. Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu
  4. Subject: Re: C/C++ knocks the crap out of Ada
  5. Date: 11 Mar 1996 13:26:40 GMT
  6. Organization: CRC for Distributed Systems Technology
  7. Message-ID: <4i19mg$vkt@azure.dstc.edu.au>
  8. References: <JSA.96Feb16135027@organon.com> <4hbj2b$cnt@sun152.spd.dsccc.com> <adaworksDnrqsE.LpC@netcom.com> <4hhred$1rn@sun152.spd.dsccc.com>
  9. Reply-To: crawley@dstc.edu.au
  10. NNTP-Posting-Host: fatcat.dstc.edu.au
  11.  
  12. In article <4hhred$1rn@sun152.spd.dsccc.com>,
  13. Kevin Cline <kcline@sun152.spd.dsccc.com> wrote:
  14. >
  15. >Well, I will now enumerate the difficulties I had porting an Ada program
  16. >with a Motif user interface from the TeleSoft compiler for Sparc-SunOS to
  17. >the Verdix compiler for MIPS/IRIX circa 1990:
  18. >
  19. >1. The TeleSoft compiler came with the IEEE Ada-POSIX bindings.
  20. >   The Verdix compiler did not; instead it supported a Verdix-defined
  21. >   API for UNIX services that was radically different.
  22.  
  23. This is not a problem that can be blamed on the Ada language but on
  24.   a) late development of standardised Ada bindings and
  25.   b) unwillingness by Verdix to implement the standard when it 
  26.      arrived, maybe as an indirect consequence of a)
  27.  
  28. >2. The syntax (pragmas) required to call C code from the two compilers 
  29. >   differed.
  30.  
  31. Fixed in Ada 95
  32.  
  33. >3. Although both compilers were 'validated', they both failed to compile
  34. >   certain LRM-comformant code, and generated erroneous object code in
  35. >   some other cases.  I concluded that the Ada validation suite
  36. >   was rather incomplete, and actually proved very little about compiler
  37. >   quality.
  38.  
  39. It is unreasonable to expect any validation suite to find all cases
  40. where a compiler diverges from the standard.  Arguably the ACVC tests
  41. should be / have been more extensive though.
  42.  
  43. Bugs in compilers are primarily the compiler vendors fault.  With the
  44. arrival GNAT, the commercial vendors have some real competition in
  45. terms of compiler quality.  If they don't come up to scratch, they
  46. are liable to lose market share.
  47.  
  48. >4. The debuggers were extremely poor and buggy when compared to dbx.
  49. >   In particular, the user interface to the Verdix debugger was one
  50. >   of the most bizarre I have ever seen.
  51.  
  52. Fixed by GNAT, or more precisely by the Ada cognisant version of gdb.
  53. [And as above, this should have the effect of indirectly improving
  54. the quality of substandard commercial debuggers.]
  55.  
  56. >6. Because Ada-83 did not allow passing procedures as parameters to
  57. >   other procedures, there was no reasonable way to create an
  58. >   API to an event-driven GUI library like MOTIF.
  59.  
  60. Fixed in Ada 95.
  61.  
  62. >5. The compilers had two completely different API's for calling 
  63. >   X and MOTIF services.
  64.  
  65. There are emerging public domain X and MOTIF bindings for Ada that
  66. (assuming they are available with GNAT sometime soon) are IMO likely
  67. to become defacto standards.
  68.  
  69. >The lack of industry standard Ada bindings to these common OS
  70. >services combined with the high expense and poor quality of the
  71. >available Ada-83 compilers made development a medium-scale portable
  72. >UNIX application in Ada much more expensive and difficult than
  73. >developing the same application in C.
  74.  
  75. Yes.  But given recent (though belated) standardisation activities and
  76. the increasing influence of the GNU / FSF movement in the Ada
  77. community, one would hope that this should be less of a problem in the
  78. future.
  79.  
  80. >Perhaps the emergence of GNAT has changed all this, but it is going
  81. >to be hard for Ada to keep up.  
  82.  
  83. Debatable.
  84.  
  85. >To use Ada in my work today, I would 
  86. >require an API to CORBA, 
  87.  
  88. Available now or soon from at least two commercial ORB vendors; i.e. look at 
  89. the following
  90.  
  91.    http://alsp.arpa.mil/corba-ada/ada-products.html
  92.  
  93. Note that the CORBA standard language bindings for Ada are expected to be
  94. formally approved at the OMG board meeting that happens on March 20th (for
  95. memory)
  96.  
  97. >Tcl/Tk, 
  98.  
  99. Check out the following:
  100.  
  101.     http://www.cs.colorado.edu/~arcadia/Software/adatcl.html
  102.  
  103. >and the Solaris real-time facilities
  104. >(itimers, etc.) and a runtime that efficiently mapped Ada tasks to 
  105. >Solaris threads.
  106.  
  107. I'm not sure, but the GNAT "features" file suggests that both may
  108. be available in GNAT 3.00 (and later versions) for Solaris.  (Though
  109. I guess it depends what you mean by efficient ...)
  110.  
  111. It is amazing what you can find with a Web search engine and some
  112. carefully chosen queries :-)
  113.  
  114. -- Steve
  115.  
  116.  
  117.